fix(server): name the process holding the port instead of a raw ServeError - #7703

What Changed

A bind failure carrying EADDRINUSE now fails as PortInUseError, which names
the port and, when server-runtime.json corroborates it, the process holding it.
Every other bind failure passes through untouched, and the original ServeError
and errno error stay attached as cause, so nothing is lost for debugging.

Corroborated:

Port 3773 on 127.0.0.1 is already in use by a running T3 Code server (pid
1080 per server-runtime.json). Stop that server first; 't3 service status'
finds it when it is the background service. If that pid is not actually a T3
server (stale descriptor, reused pid), delete '<path>' and retry.

When the state file is missing or names a different port, no culprit is invented:

Port 3773 on 127.0.0.1 is already in use. Stop whatever is listening there,
or start T3 Code on another port with --port; 't3 service status' says
whether the T3 Code background service is holding it.

holderPid is set only when the persisted state parses and its port matches the
one being bound. That is the same shape — and the same hedge about stale
descriptors and reused pids — that migrate-dev-db.ts already uses for a
database held open by a running server.

explainPortInUse wraps runServer rather than HttpServerLive. Wrapping the
layer is the more precise spot, but Layer.catchCause types the recovery as
Layer<ROut & ROut2> and a failing fallback layer has ROut2 = never, which
collapses the HttpServer output to never. Layer.launch is the first point
where the failure is an ordinary Effect error again, and ServerConfig is
already in its requirement channel, so no new requirement reaches bin.ts. The
predicate walks the cause chain for code === "EADDRINUSE" across both Fail
and Die, since @effect/platform-node fails the layer build with a ServeError
while BunHttpServer throws the errno error as a defect. Catching at runServer
is marginally broader than the bind alone; the only other server built during
startup is in the CLI auth flow, and the EADDRINUSE predicate keeps an unrelated
failure from being relabeled.

Tests: five cases in portInUse.test.ts, three of which build a real
NodeHttpServer.layer against a port held by a live net.Server, so the failure
under test is a genuine EADDRINUSE rather than a synthetic cause. They assert the
full corroborated message, the full degraded message, that a state file naming
another port does not produce a pid, that a Bun-shaped defect is still explained,
and that a ServeError wrapping EACCES comes through identical. Stubbing
explainPortInUse to identity fails four of the five. server.test.ts (124) and
bin.test.ts (17) pass, as do apps/server typecheck, lint and format. No
pre-existing failures on this path.

Why

ServeError names nothing. A user running the background service in WSL, with
the desktop app launching its own backend into the same distro on the same port,
got only this — in a log file they had to know to look for:

ERROR (#5): ServeError:
    at Server.onError (.../@effect/platform-node/dist/NodeHttpServer.js:74:26)
  [cause]: Error: listen EADDRINUSE: address already in use 0.0.0.0:3773

The server knows which port it was told to bind, and server-runtime.json is
already read by t3 triage and t3 pair to find a live server, so the answer to
"who has it" is one file read away at exactly the moment it matters.

The message names the service explicitly because that is the common way to end up
with a T3 Code server you forgot about, but it has to stay correct for a plain
npx t3 on a busy port, which is why the degraded variant claims nothing it
cannot support.

Not addressed: the pid is not liveness-checked. triage.ts and
migrate-dev-db.ts both process.kill(pid, 0) before claiming a server runs, so
there is precedent, but a second heuristic with its own false positives did not
earn its place next to a message that already hedges. Separately,
cli/config.ts:262-265 returns DEFAULT_PORT with no availability check in
desktop mode where web mode calls findAvailablePort — that is why the
reported user hit this on every relaunch, and it is a different fix.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — N/A, server-only
• I included a video for animation/interaction changes — N/A, server-only

Changes by Claude Opus 5 running in Claude Code.